home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SPACE 2
/
SPACE - Library 2 - Volume 1.iso
/
apps
/
671
/
doc
/
okami.doc
< prev
next >
Wrap
Text File
|
1992-09-20
|
85KB
|
2,169 lines
===============================================
@(#) OKAMI SHELL VERSION 1.4 - BENUTZERANLEITUNG
===============================================
Stand: 19.9.1992
BITTE ERST DIE DATEI README LESEN!
----------------------------------------------------------------------------
EINFÜHRUNG
Die Okami-Shell (man spricht es "O-Kammi") ist ein (weiterer) Versuch,
auf dem Atari ST so etwas wie Unix-Gefühle aufkommen zu lassen. Das
Programm wendet sich an alle, die die Möglichkeiten eines
Kommandointerpreters denen des Desktops vorziehen. Die Shell ist vor
allem beim Betrieb mit einer Festplatte ausgesprochen nützlich.
Obwohl es schon einige Programme dieser Art gibt, gibt es gewichtige
Gründe, die Okami-Shell zu benutzen und sich durch die folgende
Anleitung zu arbeiten.
Die Okami-Shell ist einer der Unix-orientierten Kommandointerpreter für
den ST, der die Unix-Möglichkeiten der Ein/Ausgabe-Umleitung und des
Pipelinings auch für die internen (in der Shell eingebauten) Kommandos
ermöglicht. Die Ein/Ausgabe-Umleitung ist die Möglichkeit, die
Standard-Ausgabe eines Programmes, d.h. alles, was mit printf, Cconout
etc. ausgegeben wird und normalerweise auf dem Bildschirm landet, sowie
die Standard-Eingabe in eine Datei oder zu einem Gerät (z.B. zum
Drucker) umzuleiten. Die Umleitung funktioniert unter TOS mit dem
GEM-Desktop a) nur bei TTP-Programmen, weil man nur bei diesen die
Möglichkeit hat, eine Kommandozeile einzugeben, und b) nur bei
Programmen, deren Compiler die Umleitung unterstützen. Die Okami-Shell
führt die Umleitung selber durch, wodurch auch Programme, die ihre
Kommandozeile nicht beachten (z.B. solche, die mit dem
Pd-Modula-2-System erstellt wurden), umgeleitet werden können.
Die Okami-Shell kann allerdings noch etwas mehr: sie ist ein
universelles Utility, mit dem man nicht nur Programme starten, sondern
auch Programme schreiben und debuggen usw. kann. Als Bonbon hat sie
einen eingebauten UPN-Rechner mit ca. 80 Funktionen sowie einen
Terminal-Emulator. Alles in allem bietet die Okami-Shell mehr interne
Kommandos und Funktionen als jede andere für den Atari erhältliche
Shell.
Bei der Programmierung einer Shell oder eines Kommandointerpreters
steht man immer vor der Frage, ob man für die in der Shell eingebauten
Kommandos Unix-, MS-DOS- oder eine selbstausgedachte Schreibweise
benutzen soll, d.h. ob man die Kommandos ls oder dir, mv oder rename,
cp oder copy nennen soll oder ob man sich eingene Kommandonamen
ausdenkt. Die Okami-Shell ist an den Unix-Bezeichnungen orientiert,
genauer gesagt an dem Unix-Derivat AIX, das z.B. auf dem IBM RT PC 6150
läuft. Natürlich müssen bei soetwas Abstriche gemacht werden, der Atari
ist schließlich keine Unix-Maschine, und eine Shell ist kein
Betriebssystem.
Wer sich in Unix einigermaßen auskennt, kann mit der Okami-Shell sofort
loslegen. Die folgende Anleitung stellt die Verwendung der Shell dar,
die Erklärung der internen Kommandos mit Syntax befindet sich in der
Datei commands.doc.
Um die vielen Versionen der Shell unterscheiden zu können, gibt das
Kommando `ver' eine Information mit Versionsnummer und
Kompilierungszeitpunkt aus. Zur Interpretation der Versionsnummer siehe
tricks.doc.
----------------------------------------------------------------------------
SUPPORT
Die Okami-Shell ist Public Domain, d.h. sie kann von jedermann benutzt
und weitergegeben werden, ohne daß jemand etwas dafür zu bezahlen hat.
Wer über E-Mail zu erreichen ist, sollte mir über das Maus- oder Usenet
eine kleine Nachricht, evtl. mit Kommentaren, Anregungen und Kritik,
zukommen lassen. Adresse siehe unten.
Über den Support ist es jederzeit und für jeden möglich:
1) die neueste Version der Shell zu bekommen,
2) konfektionierte Versionen zu erhalten, in denen die
Systembeschränkungen (Anzahl der Variablen, Funktionen etc.) verändert
sind. Wer also eine Version braucht, die bis zu 2000 Variablen verwalten
kann, kann eine solche bekommen. Außerdem können beliebige Kommandos
ausgeblendet werden, um die Shell kleiner zu machen. Wer also z.B. den
UPN-Rechner und das basep-Kommando nicht braucht, kann eine Shell
erhalten, in der diese Kommandos nicht enthalten sind und die somit
entsprechend kürzer ist.
3) Außerdem ist eine "CLI-Only"-Version erhältlich, die nur die
allerwichtigsten Kommandos zur Bedienung der Shell enthält. Diese
Version ist ungepackt ca. 63 KB groß (die Vollversion ca. 130 KB) und
kann auf Systemen eingesetzt werden, auf denen die wichtigsten Kommandos
als externe Programme zur Verfügung stehen.
Es ist verboten, die Shell zu verkaufen oder unter einem anderen Namen
zu vertreiben. Wer irgendwelche Teile des Programms oder der Quellen in
eigenen Programmen benutzen will, darf dies tun, solange mein Name im
Programm und in der Dokumentation erwähnt wird.
Die Datei `copying' enthält genaue Hinweise zum Kopieren und Weitergeben
der Shell.
Das Programm wird voll unterstützt, d.h. es wird dynamisch
weiterentwickelt, und jeder Anwender kann bei mir jederzeit die neueste
Version bestellen. Ebenso stehe ich bei Problemen und Wünschen zur
Verfügung. Spenden sind natürlich auch willkommen, aber ausdrücklich
nicht Vorraussetzung für den Erwerb von neuen Versionen, Anleitungen
oder sonstigen Hilfen (dies ist allen Pd-Programmierern zur Nachahmung
empfohlen).
Meine Adresse:
Wolfram Rösler
Augustastr. 44-46
W-5100 Aachen
Tel. +49 (0)241 534596
Mausnetz: Wolfram Rösler @ AC2
Usenet: wr@bara.oche.de
Bitte bei allen Zuschriften die Versionsnummer und das
Kompilierungsdatum der Shell angeben (werden durch Eingabe von "ver"
ausgegeben). Bei Fehlermeldungen bitte die Ausgabe von "ver -a"
mitschicken.
Wer irgendwelche Anregungen für weitere Versionen der Shell hat, kann
sich damit jederzeit an mich wenden.
----------------------------------------------------------------------------
PROGRAMMFEHLER
"Selbst der umsichtigste Programmierer kommt manchmal in Situationen,
wo das Programm nicht richtig funktioniert."
Texas Instuments, "Individuelles Programmieren"
Handbuch zu TI 58/58C/59, 1977
Der Software-Support deckt die Beseitigung von Fehlern in der Shell ab.
Wer einen Fehler findet, sollte also nicht die Okami-Diskette in die
Ecke schmeißen und sich einer anderen Shell zuwenden (die hat nämlich
auch Fehler), sondern mir einen Hinweis mit möglichst genauer
Fehlerbeschreibung schicken. Wenn man eine Diskette und einen
frankierten Rückumschlag beilegt, bekommt man die korrigierte Version
der Shell sobald wie möglich zurück. Wenn die Shell in Verbindung mit
einem anderen Programm Probleme macht, sollte man dieses Programm gleich
mitschicken. Bitte bei allen Fehlermeldungen die Ausgabe von "ver -a"
mitschicken.
Natürlich kann ich keine Verantwortung für irgendwelche Schäden, die
durch die Shell, ihre Anwendung oder die Unfähigkeit ihrer Anwendung
verursacht werden, übernehmen. Wer also unbedingt
df -mn | xargs rm -r {}/*
ausprobieren muß, hat das Ergebnis selber auszubaden.
----------------------------------------------------------------------------
LIEFERUMFANG
Zur Okami-Shell gehören die folgenden Dateien:
KERN:
sh.ttp Das Haupt-Shellprogramm.
msh.prg Die Microshell zum Starten als GEM-Programm.
msh.inf Konfigurationsdatei zur Microshell.
profile Konfigurationsdatei beim Start der Shell.
help Textdatei mit Syntaxerklärungen.
EXTERNE KOMMANDOS:
calc.sh Benutzerschnittstelle zum eingebauten UPN-Rechner.
format.ttp Programm zum Formatieren von Disketten.
gem.prg Programm zur Benutzung von Accessories.
gem.rsc Resourcedatei dazu.
showpic.sh Demo-Shellscript zur Anzeige von Bilddateien.
QUELLEN:
msh.c msh.prg
gem.c gem.prg
format.c format.ttp
DOKUMENTATION:
readme Grundeinführung für den Anwender.
doc\*.* Anleitungen.
SONSTIGES:
dial.inf Eine Beispieldatei für das dial-Kommando.
okami.pic Das Titelbild.
okicon.rsc Eine Resourcedatei, die drei Icons mit dem
Okami-Logo enthält.
_index Indexdatei für `ls -i'.
----------------------------------------------------------------------------
SYSTEMANFORDERUNGEN
"Wie der Name unschwer erkennen läßt, besitzt der Atari 520 ST
einen enormen Hauptspeicher, nämlich ganze 512 KByte. Der eine
oder andere kann sich vielleicht schwer vorstellen, wozu dieser
Riesenspeicher benötigt wird."
Data Becker, "Das große GEM-Buch" (1985)
Die Okami-Shell stellt folgende Anforderungen an das System:
Rechner
Läuft auf jedem ST-kompatiblen Rechner. Über den Einsatz auf anderen
Rechnern mit ST-Emulator liegen noch keine Testergebnisse vor.
RAM
Die Shell benötigt ca. 200 KB an Laufzeitspeicher => lauffähig auch
auf 512KB-Maschinen. Empfohlen werden allerdings 1 MB oder mehr.
Massespeicher
Für die zum Lauf notwendigen Dateien werden minimal ca. 120 KB
benötigt. Mit allen Hilfsdateien (Microshell, Profile,...) werden
ca. 200 KB benötigt. Dazu kommen noch die über 300 KB für die
Dokumentation.
Die Shell kann jedem Massespeicher betrieben werden. Für die
Verwendung des Pipelinings ist es jedoch notwendig, daß auf einen
Massespeicher (nicht notwendigerweise den, von dem die Shell
gestartet wurde) geschrieben werden kann. Für diesen Zweck kann
auch eine eigene kleine Ramdisk verwendet werden (16-32K).
Bildschirm
Läuft in jeder Auflösung. Der Betrieb in niedriger Auflösung ist
möglich, aber einige interne Kommandos gehen davon aus, das pro Zeile
80 Zeichen zur Verfügung stehen (z.B. df und hd). Die Benutzung
dieser Kommandos kann dann zu Störungen in der Bildschirmausgabe
führen. In keinem Fall kommt es jedoch zu einem Programmabsturz.
Sollte mit jeder Farb- und Schwarzweiß-Emulation funktionieren.
Sollte auch mit allen Großbildschirm arbeiten (ungetestet mangels
Großbildschirm). Die Shell unterstützt OverScan (siehe commands.doc
zu dem internen Kommando "overscan").
Hardware
Die Shell unterstützt Maus, Drucker und die RS232-Schnittstelle sowie
ein Modem. Es werden jedoch keine Geräte außer Bildschirm und
Tastatur unbedingt benötigt (auch nicht die Maus). (Genaugenommen
werden nicht einmal Bildschirm und Tastatur unbedingt benötigt.)
Betriebssystem
Die Shell wurde unter TOS 1.02 und 1.04 auf einem Atari 1040 ST und
Mega ST4 entwickelt und ist "sauber" programmiert, d.h. es erfolgt
kein Zugriff auf undokumentierte oder veränderliche Systemadressen
o.ä. Die Shell sollte daher mit jedem früheren und zukünftigen TOS
zusammenarbeiten. Sie arbeitet mit und unterstützt MiNT.
Software
Jedes TOS- und TTP-Programm kann von der Shell als externes Kommando
aufgerufen werden. GEM-Programme können aufgerufen werden, wenn die
Shell selber als GEM-Programm gestartet wird, was z.B. der Fall ist,
wenn msh.prg zum Start der Shell benutzt wird.
Zum Verändern der Konfigurationsdateien profile und msh.inf ist ein
Ascii-Editor erforderlich.
----------------------------------------------------------------------------
INSTALLATION
Die Okami-Shell kann direkt von der Diskette gestartet werden. Siehe
hierzu den folgenden Abschnitt.
Ihre volle Effizienz entwickelt die Shell allerdings erst beim Einsatz
von der Ramdisk oder Festplatte.
INSTALLATION AUF RAMDISK
Ich empfehle die selbstkomprimierende Maxidisk, da sie die optimale
Speicher ausnutzung garantiert. Für die Shell sollten mindestens 200 KB
Maxidisk oder ca. 300 KB einer anderen Ramdisk zur Verfügung stehen.
Für den vollen Betrieb der Shell sollten folgende Dateien (am besten in
einen eigenen Ordner) auf die Ramdisk kopiert werden:
sh.ttp
profile
msh.prg
msh.inf
help
okami.pic
dial.inf
_index
in einem Unterordner namens doc:
commands.doc <------ aus dem Anleitungsordner
in einem Unterordner namens bin:
*.sh
format.ttp
gem.prg
gem.rsc
ship.exe <------ für Festplattenbenutzer: das
ship.prg der Harddisk-Utility-Disk
Die Datei help wird für das Shell-Kommando "help" benutzt; wer diese
Datei ausdruckt und neben den Rechner legt, kann sich den Platz auf der
Ramdisk ebenfalls sparen. Dasselbe gilt für commands.doc, das außerdem
ziemlich viel Platz beansprucht. (Auf der Platte - auf dem Papier
allerdings auch, außerdem wird commands.doc für die Online-Hilfe
benötigt.)
Die Dateien msh.prg und msh.inf gehören zusammen und werden zum Start der
Shell als GEM-Programm benutzt. Wer von der Shell keine GEM-Programme
starten will, braucht diese Dateien nicht.
Auf die externen Kommandos wie gem und format kann man natürlich auch
verzichten, nur muß man dann u.U. etwas häufiger ins Desktop zurück.
Wer kein Modem hat, kann mit dem dial-Kommando nichts anfangen und
braucht folglich auch kein dial.inf.
Wer nicht bei jedem Systemstart das Titelbild sehen möchte, kann die
Datei okami.pic umbenennen oder löschen.
Auch auf profile kann man verzichten, allerdings wird die Shell dann mit
den eingebauten Voreinstellungen initialisiert.
=> Die einzige Datei, die man wirklich braucht, ist sh.ttp.
INSTALLATION AUF FESTPLATTE
Bei der Installation der Shell auf Festplatte kommt echtes Unix-Feeling
auf, vor allem wenn man die Shell nach dem Systemstart automatisch
starten läßt (ich empfehle zum Autostart:
TOS 1.0: den Autostarter aus dem Data Becker-Buch "Die besten
Tips&Tricks für Atari ST", S. 24ff.
TOS 1.2: den Autostarter "startgem.prg", der zu Superboot 6.0
gehört, siehe PD-Journal 9/90, S. 43ff.
>= TOS 1.4: msh.prg im Desktop als Autostart-Applikation anmelden)
Mit einigen Tricks, die im folgenden erklärt werden, kann man sich z.B.
bei jedem Start der Shell Datum und Uhrzeit des letzten Systemstarts
ausgeben lassen oder das aktuelle Arbeitsverzeichnis so einstellen, wie
man die Shell zuletzt verlassen hat. Außerdem kann man alle Programme,
die man auf der Festplatte hat, per Name starten lassen, egal in welchem
Verzeichnis man sich gerade befindet, und es werden sogar alle
RSC-Dateien gefunden.
Man tippt also z.B. ein:
edit datei.txt
und es erscheint der Editor mit der Datei datei.txt, egal wo im
Dateisystem der Editor sich befindet.
Für die Shell sollte ein eigener Ordner eingerichtet werden, in den die
oben unter INSTALLATION AUF RAMDISK aufgeführten Dateien kopiert werden.
Außerdem ist es sinnvoll, Pipe-Operationen über eine Ramdisk laufen zu
lassen. Siehe dazu weiter unten.
Wenn man sich die Anleitungen der Shell auf die Festplatte kopiert,
braucht man die Datei commands.doc nicht noch einmal in den Shell-Ordner
zu kopieren. Dann muß allerdings der Dateiname von commands.doc in der
Shell-Variablen HELPFILE gespeichert werden. Siehe dazu weiter unten.
INSTALLATION IM AUTO-ORDNER
Es ist sehr sinnvoll, ein kleines Programm zu schreiben, das im
Auto-Ordner gestartet wird und, wenn eine bestimmte Taste gedrückt ist,
die Shell per Pexec ausführt. Wenn dies das erste Programm im Auto-Ordner
ist, hat man immer die Gelegenheit, vor dem Start irgendwelcher Programme
in die Shell zu gelangen und so z.B. defekte Programme, die das korrekte
Hochfahren des Systems verhindern, zu deaktivieren. Die Shell führt keine
AES-Aufrufe aus, die beim Start aus dem Auto-Ordner zu Problemen führen
würden, da zu dieser Zeit das AES noch nicht initialisiert ist. Die Shell
führt AES-Aufrufe erst dann aus, wenn der Anwender sie durch Eingabe des
Kommandos `gon' explizit dazu auffordert. Aus diesem Grund ist ein
Betreiben der Shell aus dem Auto-Ordner problemlos möglich.
INSTALLATION IM COOKIE-JAR
Der Cookie-Jar ist eine Möglichkeit des Betriebssystems, mit der
installierte Programme dem System ihre Anwesenheit nebst Versionsnummer
mitteilen können. Der Cookie-Jar wird erst ab TOS 1.6 vom Betriebssystem
selber benutzt, kann aber bei allen früheren TOS-Versionen auch von
Programmen installiert werden. Die Okami-Shell trägt sich unter der
Kennung "OkSh" in den Cookie-Jar ein. Vorher installiert sie einen
solchen, falls noch keiner vorhanden ist. Die Versionsnummer ist auf zwei
Bytes aufgeteilt, bei Version 1.5 steht eine 5 im niedrigsten und eine 1
im nächsthöheren Byte.
Mit dem internen Kommando `cookie' kann der Cookie-Jar ausgelesen
werden. Siehe hierzu commands.doc.
Wenn die Shell beendet wird, wird der vorherige Wert wieder als
Cookiejar-Adresse eingetragen. Beim Beenden der Shell mit shutdown wird
als Cookiejar-Adresse 0 eingetragen.
----------------------------------------------------------------------------
START DER SHELL
a) Direkt
Die Shell wertet ihre Kommandozeile nach der folgenden Syntax aus:
[-] [Flags] [[-- | -c] Cmd [Parameter]]
Es bedeuten:
-
Es wird die Datei profile im aktuellen Directory geladen. Wenn -
nicht angegeben ist, wird keine Profile-Datei geladen. (In Unix wird
das - als erstes Zeichen von argv[0] übergeben. Das läßt sich in TOS
nicht bewerkstelligen, also muß das - in der Kommandozeile stehen.)
Flags
Beliebige der Flags, die auch für das Kommando set benutzt werden
können und das Verhalten der Shell global beeinflussen. Die Flags
können also schon in der Kommandozeile eingestellt werden, was
nützlich ist, wenn kein Profile benutzt wird. Die Flags können mit +
oder - beginnen. Siehe commands.doc für weitere Details.
--
Stellt das Ende der Flags dar und signalisiert, daß die weiteren
Parameter zu `Cmd' gehören. -- wird nur benötigt, wenn `Cmd' mit
einem Minus- oder Pluszeichen beginnt.
-c
Signalisiert, daß es sich bei `Cmd' um ein auszuführendes Kommando
(intern oder extern) handelt. Wenn -c nicht benutzt wird, wird `Cmd'
als der Dateiname eines auszuführenden Shellscripts betrachtet.
Cmd
Ein auszuführendes Kommando oder Shellscript. Wenn Cmd angegeben
ist, wird die Shell nach seiner Ausführung beendet. Wenn kein Cmd
angegeben ist, wird die Shell interaktiv.
Para
Optionale Parameter für Cmd.
Anmerkung: Über den Software-Support kann eine Shell bezogen werden, die
sich im Hinblick auf das übergebene Minuszeichen genau andersherum
verhält, d.h. sie initialisiert sich mit dem Profile immer, außer es wird
ein Minuszeichen übergeben.
Beispiele:
sh
Die Shell wird interaktiv gestartet. Es wird kein Profile geladen.
sh -
Die Shell wird interaktiv gestartet. Die Datei profile im aktuellen
Directory oder (falls gesetzt) die in der Environment-Variablen
OKSH_PROFILE angegebene Datei wird geladen. Dies ist der normale
Start der Shell.
sh - -i
Die Shell wird interaktiv gestartet, die Datei profile wird geladen,
und es wird der Insert-Modus des Zeileneditors abgeschaltet (-i).
sh myscript
Die Datei myscript wird als Shellscript ausgeführt, danach wird die
Shell beendet.
sh -x myscript
Die Datei myscript wird als Shellscript ausgeführt, danach wird die
Shell beendet. Vorher wird das Flag x gelöscht, wodurch die Shell
beim Start von Binärprogrammen das aktuelle Verzeichnis nicht auf
das Verzeichnis einstellt, in dem die Programmdatei enthalten ist.
sh -L <myscript
Das Flag L wird gelöscht, wodurch die Shell Kommandos von der
Standardeingabe (statt mit dem Zeileneditor von der Tastatur)
einliest. Dadurch wird die Datei myscript ausgeführt. Diese Art des
Startens eines Shellscripts unterscheidet sich nur geringfügig von
dem direkten Angeben des Shellscripts und kann z.B. benutzt werden,
um Kommandos von einer Pipeline oder einer Schnittstelle auszuführen.
sh -c ver
Die Shell führt das Kommando `ver' aus und terminiert.
b) Indirekt
Die Shell kann indirekt von jedem Programm aus mit der GEMDOS-Funktion
Pexec gestartet werden. Dies geschieht z.B. beim Aufruf von der
Microshell. Da die Shell den Environment-String benutzt, sollten
Programme, die das nicht tun, als letzten Parameter von Pexec eine
(long)0 übergeben (und nicht einen Leerstring). Wenn der Shell dabei ein
Parameterstring übergeben wird, so wird dieser wie oben beschrieben
ausgeführt. Der Parameterstring kann der Shell auch nach dem xArg- oder
ARGV-Verfahren übergeben werden.
Wenn die Shell als Login-Shell gestartet werden soll und es möglich sein
soll, GEM-Programme von der Shell aus zu starten, muß die Shell mit der
Microshell (msh.prg) gestartet werden. Dazu müssen folgende
Voraussetzungen zutreffen:
1) Im selben Directory wie sh.ttp stehen die Dateien msh.prg und msh.inf.
2) Die Datei msh.inf enthält mindestens die folgende Zeile:
sh.ttp -
Dann wird die Shell nach Doppelklick auf msh.prg automatisch als
Login-Shell gestartet. Es können alle GEM-Programme von der Shell aus
ausgeführt werden. Siehe hierzu auch msh.doc.
Wenn die Shell auf diese Weise vom Desktop aus gestartet wird, sollte
das Profile die Zeile
trap cursor -v
enthalten. Dann wird nach dem Ende der Shell automatisch der Cursor abge
schaltet (auf dem Desktop stört er ziemlich). Siehe hierzu auch
commands.doc.
c) Über den Shellpointer (_shell_p)
Der Shellpointer befindet sich in Adresse 0x4F6 und enthält einen Zeiger
auf eine Funktion, die ein ihr übergebenes Kommando ausführt. Auf diese
Weise ist es möglich, aus einem von der Shell gestarteten Programm aus
Shellkommandos auszuführen, ohne daß die Shell nochmal geladen werden
muß. Ein Beispiel für die Verwendung ist das mitgelieferte gem.prg.
Die Funktion, deren Adresse in 0x4F6 hinterlegt wird, hat folgende
Syntax:
int Fct(char *cmd)
`cmd' ist ein String mit dem auszuführenden Kommando. Dies kann ein
beliebiges Shell-Kommando sein. Mehrere Kommandos können durch `;'
verkettet werden. Wenn ein leerer String oder ein NULL-Zeiger übergeben
wird, arbeitet die Shell im Dialogmodus, ansonsten wird nur cmd
ausgeführt. Zurückgegeben wird der Rückgabewert des Kommandos.
Achtung: Bei dieser Art des Aufrufes wird die bereits laufende Shell
ausgeführt. Das bedeutet, daß alle Shellvariablen und Shellfunktionen der
laufenden Shell benutzt und verändert werden können. Die vollständige
Reentranz der Shell kann jedoch nicht garantiert werden. Insbesondere
sollten mit einer auf diese Weise gestarteten interaktiven Shell keine
externen Programme aufge rufen werden. (was allerdings teilweise möglich
ist und offenbar von dem betreffenden Programm abhängt.)
---------------------------------------------------------------------------
KONFIGURATION
Wenn der Shell als einziger Parameter ein Minuszeichen übergeben wird,
sucht sie nach dem Start im aktuellen Verzeichnis eine Datei mit dem
Namen profile. Wenn die Environment-Variable OKSH_PROFILE gesetzt ist,
wird stattdessen die in dieser Variable angegebene Datei benutzt. Wenn
diese Datei vorhanden ist, wird sie wie ein Shellscript (siehe dazu
weiter unten) ausgeführt. Das Profile kann eine Einschaltmeldung auf dem
Bildschirm ausgeben und Shellvariablen wie z.B. das Prompt (PS1) setzen.
Außerdem können die Shell-Flags eingestellt werden (siehe dazu das in-
terne Kommando `set' in commands.doc). Das Profile kann alle Aktionen
ausführen, die ein normales Shellscript auch ausführen kann. Siehe hierzu
auch tricks.doc.
----------------------------------------------------------------------------
KOMMANDOEINGABE
a) Von der Tastatur
Wenn die Shell im Dialogmodus gestartet ist, können nach dem Prompt
(i.d.R. ein Dollarzeichen) Kommandos eingegeben werden. (Das
mitgelieferte Profile stellt das Prompt um, so daß im Prompt immer das
augenblickliche aktuelle Directory zu sehen ist.)
Mit dem internen Kommando keydef kann jede beliebige Taste umdefiniert
werden. Das bedeutet, daß alle der unten angeführten Tastenfunktionen
ungültig werden können, wenn die jeweiligen Tasten umdefiniert werden.
Die einzigen Funktionen, die nicht umdefiniert werden können, sind ENTER
und Ctrl Shift Undo. Für weitere Informationen siehe commands.doc zum
Thema keydef.
Bei der Eingabe werden folgende Sondertasten benutzt:
Backspace
bewegt den Cursor nach links und löscht das dort stehende Zeichen.
Pfeil auf
Es wird das zuletzt eingegebene Kommando angezeigt. Dieses kann mit
ENTER übernommen oder mit Backspace editiert werden. Durch
wiederholten Druck auf Pfeil auf wird das vorletzte Kommando
angezeigt usw. Es werden maximal 100 Kommandos gespeichert (wer mehr
braucht, benutze den Software-Support, um eine entsprechend
angepaßte Version der Shell zu erhalten.) Diese Eigenschaft der
Eingabe nennt man "History".
Shift Pfeil auf
Wie Pfeil auf, aber es wird die letzte Zeile aus der History
angezeigt, die mit der bisherigen Eingabe übereinstimmt. Gibt man
also ein "ls " und drückt Shift Pfeil auf, dann wird das letzte
ls-Kommando zurückgeholt. Der Zeiger in der History-Liste steht dann
hinter dieser Zeile, ein weiterer Druck auf Shift Pfeil Auf bringt
also das vorletzte ls-Kommando zurück usw.
Ctrl Pfeil auf
Wie Pfeil auf gefolgt von einem Druck auf ENTER, es wird also das
zuletzt eingegebene Kommando nicht nur angezeigt, sondern auch
ausgeführt. Geht auch zusammen mit Shift.
Pfeil ab
Zeigt das nächste Kommando in der History-Liste an. Mit Pfeil auf
und Pfeil ab kann man also in den in der History-Liste gespeicherten
Kommandos blättern.
Shift Pfeil ab
Analog zu Shift Pfeil auf.
Ctrl Pfeil ab
Wie Pfeil ab gefolgt von einem Druck auf ENTER, analog zu Ctrl Pfeil
auf.
Shift Esc
Dateinamen-Vervollständigung für alle Dateien, die auf ein Suchmuster
passen. Siehe unten.
Esc
Dateinamen-Vervollständigung für eine Datei. Siehe unten.
Pfeil links/rechts
bewegen den Cursor: mit Shift zum Zeilenanfang/ende, mit Control
jeweils ein Wort nach links/rechts, sonst jeweils ein Zeichen nach
links/rechts.
Delete
mit Control: löscht die Zeile von der Cursorposition bis zum
Zeilenende. Sonst: löscht das Zeichen unter dem Cursor.
Shift Space
Speichert die aktuelle Position für Pfeil rechts. Siehe unten.
Clr-Home
Die Eingabezeile wird gelöscht.
Help
Es wird eine Erklärung des eingegebenen Kommandos ausgegeben. Siehe
unten.
Ctrl Shift Undo
Für diese Eingabezeile wird die Tasten-Redefinition ausgeschaltet.
Die Eingabe verhält sich also so, als ob seit dem Start der Shell
keine keydef-Kommandos ausgeführt worden wären. Die Funktion wird
durch ein Klingelzeichen bestätigt.
Control V
Das nächste eingegebene Zeichen wird nicht als Steuerzeichen
interpretiert. Auf diese Weise kann man z.B. VT52-Sequenzen eingeben:
echo <ESC>E
geht nicht, da das ESC interpretiert wird (und Filename-Completion
einleitet), man muß es so eingeben:
echo <Ctrl-V><ESC>E
Control F
Es erscheint eine Fileselect-Box, der ausgewählte Dateiname wird in
die Eingabe übernommen. Das geht nur, wenn gon aktiv ist (siehe
commands.doc zum Stichwort gon).
Control P
Es wird eine Hardcopy ausgeführt. Dies geschieht durch Aufruf der
Shellfunktion "screensave". Die Voreinstellung dieser Funktion ist
ein einfacher Aufruf des internen Kommandos "hardcopy", wodurch der
Bildschirminhalt auf dem Drucker ausgegeben wird. In der Datei
`tricks.doc' ist eine screensave-Funktion angegeben, durch die die
Hardcopy in eine Datei geschrieben wird.
Control A
Der Bildschirm wird dunkelgeschaltet. Nach Druck auf eine der
Shifttasten, Control oder Alternate kann man weiterarbeiten. (Um
diese Funktion zu benutzen, sollte gon aktiv sein, da sie dann
VDI-Funktionen benutzen kann; wenn gon nicht aktiv ist, schreibt sie
direkt in den Bildschirmspeicher, was bei Großbildschirm usw. nicht
funktioniert.)
Alternate Space
Es werden Uhrzeit und Datum angezeigt, bis die Alternate-Taste
losgelassen wird.
Control D
Die Shell wird beendet.
Es können beliebige Ascii-Codes in der Schreibweise `^ooo' eingegeben
werden, wobei ooo eine dreistellige Oktalzahl ist. Um z.B. Klingelzeichen
in eine Eingabe einzubauen:
echo "Jetzt kommt eine Klingel: ^007"
Auf diese Weise können alle VT52-Sequenzen benutzt werden. Siehe auch
`echo' in commands.doc.
Dateinamen-Vervollständigung (Filename-Completion):
Die Shell bietet die Möglichkeit, nur einen Teil eines Dateinamens
einzugeben und diesen dann zu dem vollen Dateinamen expandieren zu
lassen. Dazu gibt es zwei Möglichkeiten:
1) Nach Druck auf Taste Shift-Escape wird das zuletzt eingegebene Wort
zu allen Dateinamen expandiert, die nach den Regeln der erweiterten
Wildcards auf dieses Wort passen. Beispiel:
$ cat *.c<SHIFT ESC>
erzeugt
$ cat sh.c cmds.c utl.c ...
2) Nach Druck auf die Taste ESC kann der Anwender aus den auf das letzte
Wort passenden Dateien eine auswählen. Wenn nur eine Datei paßt, wird
diese direkt übernommen, ansonsten kann eine Datei mit folgenden Tasten
ausgewählt werden:
Pfeil links/rechts
die jeweils nächste/vorige Datei.
Pfeil auf/ab
zum Anfang/Ende der Liste.
Leertaste
Dateilänge und Anzahl der passenden Dateien wer den ausgegeben.
Hierbei bedeutet `4/10' die vierte Datei von insgesamt zehn.
Return
der gerade angezeigte Dateiname wird übernommen.
ESC
die Auswahl wird abgebrochen, die bisherige Eingabe bleibt
unverändert.
Clr-Home
die Auswahl wird abgebrochen, das Suchmuster wird aus der Eingabe
entfernt.
Help
eine Tastenübersicht wird angezeigt.
Sowohl für Pfeil links als auch für ESC gilt, daß die Funktion des
eingegebenen Wortes mit dem Shell-Flag f verändert werden kann. Wenn
dieses Flag gesetzt ist (set +f), dann stellt das eingegebene Wort ein
Präfix dar, z.B. steht `abc' dann für alle Dateien, deren Name mit abc
anfängt. Wenn das Flag f nicht gesetzt ist (set -f), steht das
eingegebene Wort nur für die Dateien, die (nach den Regeln für erweiterte
Wildcards) auf dieses Wort passen, `abc' steht dann also nur für die
Datei abc.
Zur Verwendung der Help-Taste:
Mit der Help-Taste kann jederzeit, und zwar ohne die Eingabe zu stören,
zu einem Kommando die entsprechende Anleitung aus der Datei
`commands.doc' oder einer anderen Hilfsdatei angezeigt werden. Will man
z.B. eine Diskette formatieren, so tippt man das Kommando "format" ein
und überlegt dann, wie die Parameter noch waren - dann hilft ein Druck
auf Help, und es erscheint die Anleitung zu format.
Anschließend kann die Eingabe fortgesetzt werden. Das funktioniert auch,
wenn bereits Parameter nach format eingegeben worden sind.
Wenn man die Help-Taste bei leerer Kommandozeile drückt, wird man nach
dem zu erklärenden Kommando gefragt.
Bei der Angabe des zu erklärenden Kommandos gelten die Regeln für
erweiterte Wildcards, d.h. mit "r*" wird das erste Kommando erklärt, das
mit r beginnt usw.
Beispiel:
$ format A: <HELP> Eingabe
format - Formatieren von Disketten Ausgabe
..... (usw.)
$ format A: * weiter gehts
(In diesem Beispiel steht <HELP> für das Drücken der Help-Taste und *
für die Cursor-Position am Ende. $ ist das Shell-Prompt.)
Der Pfadname der Datei commands.doc muß in der Shell-Variablen HELPFILE
gespeichert sein. Die Voreinstellung ist $HOME\doc\commands.doc. Wenn die
Variable HELPFILE nicht gesetzt ist, wird die Datei help.txt im aktuellen
Directory benutzt.
Wenn das Stichwort in der in HELPFILE angegebenen Hilfsdatei nicht
gefunden wird, sucht die Shell nach einer Datei folgenden Namens:
pfad\name.ext
`pfad' ist einer der in der Shell-Variablen MANPATH angegebenen Pfade,
und `ext' ist einer der in der Shell-Variablen MANEXT angegebenen
Extender. `name' ist das eingegebene Stichwort. Das Suchen der Datei
erfolgt analog zum Suchen einer Programmdatei mit den Variablen PATH und
SEXT/XEXT.
Beispiel: MANPATH=$HOME/doc, MANEXT=.doc, Eingabe: lharc. Dann sucht die
Shell nach einer Datei namens $HOME/doc/lharc.doc. Die Datei wird, falls
gefunden, mit den eingebauten Kommando pg angezeigt.
Um möglichst schnellen Zugriff auf die Hilfsdatei zu ermöglichen,
erstellt die Shell nach dem Laden einen Index, in dem die einzelnen, in
der Datei enthaltenen Kommandos verzeichnet sind. Dieser Index wird nach
der Erstellung in eine Datei abgespeichert, die denselben Pfad und
Dateinamen wie die Hilfsdatei, aber den Extender .idx hat (z.B.
commands.idx). Beim nächsten Laden der Hilfsdatei wird der Index aus
dieser Datei geladen, was besonders bei Festplatten eine enorme
Beschleunigung gegenüber dem Neuerstellen des Index im Speicher
darstellt.
Wenn die Hilfsdatei neuer ist als die Indexdatei, wird ebenfalls ein
neuer Index erstellt und abgespeichert. Dadurch wird erreicht, daß die
Indexdatei immer zu der Hilfsdatei paßt, auch wenn letztere verändert
wird. Wenn man eine neue Indexdatei erstellen will, genügt es, die alte
Indexdatei zu löschen.
Die Verwendung einer Indexdatei kann mit dem Shell-Flag -H unterbunden
werden. Dies ist wichtig für Diskettenbenutzer, bei denen das Laden der
Indexdatei länger dauert als die Neuerstellung des Index im Speicher.
Siehe hierzu commands.doc zum Thema `set'.
Anstelle von commands.doc kann auch jede andere Datei als Hilfsdatei
benutzt werden. Damit ein Kommando in der Datei erkannt wird, muß die
Datei folgende Regeln erfüllen:
1) Vor dem Text, der das Kommando erklärt bzw. der zu dem Kommando
ausgegeben werden soll, muß eine Zeile stehen, die mit fünf Minuszeichen
beginnt.
2) Direkt nach dieser Zeile muß eine Zeile stehen, die mit dem Kommando
beginnt. Das Kommando geht vom Anfang der Zeile bis (exkl.) zum ersten
Nicht-Buchstaben (Buchstaben sind a-z und A-Z, keine Umlaute, kein ß) und
darf maximal 10 Zeichen lang sein. Danach können weitere Informationen
stehen, die nicht beachtet werden.
3) Der auszugebene Text beginnt mit der unter 2) beschriebenen Zeile und
geht bis zur nächsten Zeile, die mit fünf Minuszeichen beginnt (exkl.).
Beispiel:
----- 1)
ls - Anzeigen von Directories 2)
3)
(Weitere Angaben) 4)
5)
----- 6)
Bei der Eingabe von "ls <HELP>" werden die Zeilen 2) bis 5) ausgegeben.
Natürlich kann man auch eine Kopie von commands.doc anfertigen und dort
einige weitere beliebige Informationen eintragen, die unter
entsprechenden Stichworten abgefragt werden können.
Die Ausgabe erfolgt wie mit dem Kommando "pg". Siehe hierzu
commands.doc.
TECHNISCHER HINWEIS
Wenn die Hilfsdatei im Speicher steht und von der Shell aus ein anderes
Programm gestartet wird, übergibt die Shell diesem in der
Environment-Variablen _HELP_ADR die Adresse eines Pointers auf die
geladene Hilfsdatei. Auf diese Weise kann eine Subshell auf die bereits
geladene Datei zugreifen, ohne diese selber laden zu müssen (was einen
nicht unerheblichen Aufwand an Speicherplatz bedeuten würde.)
Die Shell liest den Inhalt von _HELP_ADR direkt nach der Initialisierung
der Variablen aus dem Environment und löscht danach die Shellvariable
_HELP_ADR. Beim Aufruf weiterer Programme wird diese Variable nur
während der Erstellung des Environments für das neue Programm angelegt.
Die Variable _HELP_ADR ist also für den Anwender der Shell niemals
sichtbar, befindet sich aber im Environment aller gestarteten Programme.
Für die Übergabe ist es notwendig, daß noch mindestens ein Platz in der
Variablentabelle frei ist.
Das Format von _HELP_ADR ist
0xAAAAA:0xBBBBB
, wobei AAAAA die Adresse eines Pointers ist (hexadezimal). Dieser
Pointer zeigt auf den Text der geladenen Datei. 0xBBBBB ist die Adresse
einer internen Indextabelle, die die Shell zum schnellen Zugriff auf die
geladenen Daten benutzt. Diese Indextabelle ist ein Array von Strukturen
des Typs
struct
{
char Name[12];
long Offset;
} HelpIdxTyp;
`Name' ist der Name eines Kommandos und `Offset' ist die Byte-Entfernung
der Erklärung dieses Kommandos von dem Beginn des Textes (der durch den
Zeiger in der Adresse 0xAAAAA angegeben wird). Das Ende dieser Tabelle
ist durch einen Eintrag mit Offset=-1L markiert.
Die angelegte Indexdatei stellt ebendiesen Array dar.
(0xAAAAA ist also vom Typ (char **), während 0xBBBBB vom Typ
(HelpIdxTyp*) ist.) ACHTUNG: auf keinen Fall darf der Pointer verändert
werden.
b) Von der Standardeingabe
Wenn das Flag L nicht gesetzt ist, ist der Zeileneditor ausgeschaltet,
und die Shell liest Kommandos von der Standardeingabe. Das bedeutet, daß
weder die Editierfunktionen noch die sonstigen Funktionen des
Zeileneditors, wie Filename Completion, Fileselect-Box, Help-Taste usw.
zur Verfügung stehen. Der Sinn dieses Modus ist, Kommandos von etwas
anderem als der Tastatur, z.B. von einer Schnittstelle, einer Datei oder
einer Pipe, einzulesen.
Um den Zeileneditor schon beim Start der Shell auszuschalten, muß beim
Start von sh.ttp das Flag -L angegeben werden. Innerhalb der Shell kann
dieselbe Wirkung durch Eingabe von "set -L" erreicht werden. Mit "set +L"
wird der Zeileneditor wieder eingeschaltet.
Wenn der Zeileneditor abgeschaltet ist, kann die Shell nur durch Eingabe
von "exit" oder durch Druck auf Ctrl-Z beendet werden.
c) Aus einer Datei
Es ist möglich, Dateien zu schreiben, die Shell-Kommandos enthalten und
diese Dateien Kommando für Kommando von der Shell ausführen zu lassen.
Solche Dateien werden als Shell-Scripts (oder in der MS-DOS-Welt als
Batch-Dateien) bezeichnet. Ein Shell-Script kann wiederum weitere
Scripts ausführen usw., wobei die Tiefe der Schachtelung durch den zur
Verfügung stehenden Speicher begrenzt ist. Rekursive Shellscripts sind
natürlich auch möglich.
Für die Kommandos in Shell-Scripts gelten dieselben Regeln wie für
Kommandos, die über die Tastatur eingegeben werden.
Wenn MiNT installiert und das Shell-Flag -r gesetzt ist, dann führt die
Shell jedes Shellscript in einer Subshell aus, d.h. die Shell kopiert
sich selber, und die Kopie führt das Shellscript aus. Das hat den
Vorteil, das Scripts set-Einstellungen, Variablen usw. ändern können,
ohne diese nachher wiederherstellen zu müssen. Wer wenig Speicher hat,
sollte auf diese Möglichkeit allerdings besser verzichten.
Da das Script in einer Kopie der aktuellen Shell ausgeführt ist, findet
es dieselbe Arbeitsumgebung wie diese Shell, d.h. insbesondere alle
Shellvariablen, auch wenn diese nicht exportiert sind.
Ohne MiNT oder wenn das Shell-Flag -r nicht gesetzt ist führt die Shell
alle Shellscripts selber aus. Das bedeutet, daß das Script Variablen und
sonstige Einstellungen in der ausführenden Shell verändern kann.
Bei der Ausführung eines Shellscripts wird das Script erst vollständig in
den Speicher geladen und dann im Speicher ausgeführt. Das liefert
besonders bei der Ausführung von Diskette enorme
Geschwindigkeitsvorteile.
Bei Shellscripts gibt es die Möglichkeit, Programmierstrukturen wie if
und while zu benutzen, die bei Tastatureingabe wenig Sinn machen. Damit
ist es in der Tat möglich, Shellscripts zu schreiben, die wie ein
Programm einer höheren Programmiersprache laufen. Siehe hierzu showpic.sh
und commands.doc.
Es gibt vier Arten von Kommandos:
1) interne Kommandos,
2) externe Kommandos,
3) Shellfunktionen,
4) Kommentare.
INTERNE KOMMANDOS
Ein internes Kommando ist ein Kommando, durch das eine Funktion innerhalb
der Shell ausgeführt wird, das also in der Shell eingebaut ist. Interne
Kommandos werden durch Eingabe ihres Namens aufgerufen.
Genaue Erklärungen aller interner Kommandos befinden sich in der Datei
commands.doc.
EXTERNE KOMMANDOS
Ein externes Kommando ist nicht in der Shell eingebaut, sondern in einer
Datei auf einer Diskette, Ramdisk oder Festplatte vorhanden. Hierbei kann
es sich sowohl um eine ausführbare Datei (.PRG, .TOS etc.) als auch um
ein Shellscript handeln.
Externe Kommandos können durch Eingabe des vollständigen Pfadnamens der
entsprechenden Datei, aber auch durch Eingabe des Kommandonamens (des
Dateinamens ohne Pfad und Extender) gestartet werden. Die zugehörige
Datei wird auf den Pfaden gesucht, die in der Shell-Variablen PATH
gespeichert sind.
Mit dem hash-Kommando kann der Pfad eines Kommandos der Shell mitgeteilt
werden, ohne daß er in $PATH enthalten ist.
Externe Kommandos können nur ausgeführt werden, wenn ihr Datei-Extender
einem der in den Shell-Variablen XEXT und SEXT gespeicherten entspricht.
(Es kann jedoch jede Datei, unabhängig vom Dateinamen, explizit als
Shellscript oder Binärdatei ausgeführt werden, und zwar mit den
Kommandos `.' und `exec'.) Siehe hierzu auch den Abschnitt über externe
Kommandos in commands.doc.
Externen Programmen werden die Parameter nach dem xArg-Verfahren
übergeben, wenn das Shell-Flag `a' gesetzt ist (siehe commands.doc zum
Thema `set'). Dies ermöglicht die Übergabe von beliebig vielen
Parametern, während Gemdos die Parameter auf 125 Zeichen beschränkt.
Achtung: einige (wenige) Programme vertragen sich damit nicht und laufen
nur, wenn die xArg-Übergabe mit `set -a' unterbunden wird. Dazu gehört
z.B. der Entpacker `unzip'.
Wenn der Aufruf eines externen Kommandos von einem `&' gefolgt ist, z.B.
c:/mint/getty.ttp u:/dev/tty1 &
, dann wird das Programm als Hintergrundprozeß gestartet, die Shell läuft
also weiter, während das Programm läuft. Die Prozeßnummer des
Hintergrundprozesses wird auf dem Bildschirm ausgegeben.
Die Standardausgabe des Programmes wird dadurch nicht umgeleitet, d.h.
wenn ein Hintergrundprozeß Ausgaben macht, dann erscheinen diese
ebenfalls auf dem Bildschirm und vermischen sich ggfs. mit denen der
Shell. Daher sollte beim Aufruf eines Hintergrundprozesses immer die
Ausgabe umgeleitet werden, notfalls nach NULL: (oder u:/dev/null).
SHELLFUNKTIONEN
Shellfunktionen sind Shellscripts, die resident im Speicher gehalten
werden. Sie haben dieselben Eigenschaften wie Shellscripts und können
deshalb auch genauso programmiert werden. Alles, was über die Verwendung
von Shellscripts gesagt wird, gilt auch für Shellfunktionen.
Jede Shellfunktion hat einen Namen, der bis zu 80 Zeichen lang sein
darf. Groß- und Kleinschreibung wird unterschieden, d.h. "hallo" und
"Hallo" sind zwei verschiedene Shellfunktionen.
Bei der Ausführung haben Funktionen die oberste Priorität, kommen also
noch vor den internen Kommandos. Es ist also möglich, interne Kommandos
umzudefinieren, indem man eine Shellfunktion mit demselben Namen anlegt.
Innerhalb dieser Funktion kann auf das ursprüngliche Kommando
zugegriffen werden, indem man dem Kommando ein Ausrufezeichen (ohne
Leerzeichen) vorstellt.
Die Syntax einer Deklaration von Shellfunktionen ist:
[Funktionsname] "(" Dateiname ")" (1)
oder
Funktionsname "()" (2)
"{"
{Zeilen des Funktionsrumpfes}
"}"
oder
Funktionsname "()" (3)
"{}"
(1) In der ersten Fassung wird die angegebene Datei als Shellscript in
den Speicher geladen und unter dem Namen der Funktion abgespeichert.
Wenn kein Funktionsname angegeben ist, wird der Basisname des Dateinamens
(ohne Extender) als Funktionsname benutzt. In dieser Fassung entspricht
die Shellfunktion also einem speicherresidenten Shellscript.
Wenn die angegebene Datei eine ausführbare Programmdatei ist, wenn also
ihr erstes Wort 0x601a ist, wird das Programm geladen und eine
Shellfunktion erzeugt, die das Programm mit `exec -x' startet. Auf diese
Weise ist es möglich, auch Binärprogramme resident im Speicher zu halten
und ohne Disketten- oder Plattenzugriffe beliebig oft zu starten.
ACHTUNG: Die Vorgehensweise dabei beruht auf der Fähigkeit der
Gemdos-Funktion Pexec, Binärprogramme zu laden und erst zu einem späteren
Zeitpunkt unter Angabe der Basepage-Adresse zu starten. Die Dokumentation
von Atari zu diesem Feature ist kurz und eindeutig; sie lautet: "Finger
davon". Nichtsdestoweniger funktioniert es, aber es besteht keine
Garantie, daß es immer oder mit allen Programmen oder
Betriebssystemversionen funktioniert.
(2) In der zweiten Fassung wird die Funktion von der Tastatur oder dem
Shellscript, in dem die Deklaration steht, gelesen. Wenn bereits eine
Funktion mit dem angegebenen Namen existiert, wird sie umdefiniert.
Wenn der Funktionsrumpf leer ist, wenn also die Zeilen mit `{' und `}'
direkt aufeinander folgen, wird die Funktion gelöscht.
In dieser Fassung wird die Eingabe verkürzt, d.h. Leerzeilen,
Kommentarzeilen und führende Leerzeichen werden nicht mit abgespeichert.
(3) In der dritten Fassung wird die Funktion gelöscht. Das geht auch mit
dem Kommando `unset Funktionsname'.
Die zweite und dritte Fassung erwarten also mehr als eine Zeile. Die
weiteren Zeilen der Deklaration werden von der sog. "Sekundäreingabe"
erwartet, also von dem Gerät oder der Datei, von der augenblicklich
Kommandos gelesen werden (das ist nicht immer die Standardeingabe). Wenn
es sich dabei um die Tastatur handelt, erscheint als Prompt der Inhalt
der Shellvariablen PS2.
ACHTUNG: In keinem Fall darf zwischen Funktionsname und der geöffneten
Klammer ein Leerzeichen stehen.
Beispiele:
hallo(hallo.sh)
initialisiert eine Funktion namens "hallo". Die Funktion entspricht
dem Shellscript hallo.sh.
hallo (hallo.sh)
ruft das Kommando hallo mit dem Parameter (hallo.sh) auf, ist also
KEINE Deklaration einer Shellfunktion. (Schuld daran ist das
Leerzeichen nach "hallo".)
(c:/bin/test.sh)
initialisiert eine Funktion aus der Datei c:/bin/test.sh. Da kein
Funktionsname angegeben ist, wird der Basisname der Datei benutzt,
es wird also die Shellfunktion "test" erzeugt. (Nebenbei bemerkt:
dadurch wird das interne Kommando "test" umdefiniert.)
(c:/bin/hallo.prg)
lädt das Programm hallo.prg und erzeugt eine Shellfunktion namens
hallo, die das geladene Programm startet. hallo hat dabei folgenden
Funktionsrumpf:
exec -lg c:/bin/hallo.prg 0xnnnn
wobei nnnn die beim Laden ermittelte Adresse der Basepage von
hallo.prg ist (hexadezimal).
hallo()
{
echo Hallo, wie gehts?
read _
echo Es freut mich, daß es Dir $_ geht.
unset _
}
definiert die Funktion `hallo' mit dem angegebenen Funktionsrumpf.
Die Verwendung von Shellvariablen ist möglich; in diesem Fall wird
die Variable _ (Underscore) benutzt, die für temporäre Verwendungen
zur Verfügung steht. Diese Deklaration kann sowohl in einem
Shellscript stehen als auch über die Tastatur eingegeben werden. Bei
Tastatureingabe erscheint das Prompt $PS2.
ls()
{
!ls -C $*
}
Das interne Kommando ls wird so umdefiniert, daß die Option -C immer
aktiv ist. Dies geschieht durch Definition einer Shellfunktion mit
Namen ls, die das interne Kommando durch !ls aufruft.
alias ls !ls -C
hat dieselbe Wirkung.
hallo()
{}
Die Shellfunktion hallo wird gelöscht.
hallo()
{
}
Dito.
unset hallo
Dito.
()
(weder Funktions- noch Dateiname angegeben) ist ein Syntaxfehler.
Mit dem internen Kommando "fcts" kann eine Liste sämtlicher
Shellfunktionen erzeugt werden. Die Definition einer beliebigen
Shellfunktion kann mit dem Kommando "type" ausgegeben werden. Siehe
hierzu commands.doc.
Es gehört zur Philosophie von Unix, daß man an der reinen Eingabe nicht
erkennen kann, ob es sich bei dem eingegebenen Kommando um ein internes
Kommando, eine ausführbare Datei, ein Shellscript oder eine Shellfunktion
handelt. Um das herauszufinden, gibt es das interne Kommando `type'.
Siehe hierzu commands.doc.
KOMMENTARE
Eine Eingabe gilt als Kommentar, wenn sie mit einem Doppelkreuz (#)
beginnt oder wenn sie nur aus einer leeren Zeile besteht. Kommentare
werden von der Shell nicht weiter beachtet und sind nützlich zum
Dokumentieren von Shellscripts. Die Tastatureingabe von Kommentaren ist
zwar möglich, aber nicht unbedingt sinnvoll.
---------------------------------------------------------------------
ERWEITERTE WILDCARDS
Die Okami-Shell erlaubt für die Angabe von Dateinamen ein
Wildcard-System, das weit über das von Gemdos gestellte hinausgeht. Die
einzigen Gemdos-Wildcards sind * und ?, wobei ein ein Dateiname nur einen
Stern enthalten darf, und den nur am Ende von Name oder Extender. Bei
"**" gibt es Probleme, "*hallo*" liefert nicht alle Dateinamen, die
"hallo" enthalten usw.
Die erweiterten Wildcards der Okami-Shell orientieren sich an denen, die
von der Original-Unix-Shell zur Verfügung gestellt werden. Es bedeuten:
* beliebig viele, auch null, beliebige Zeichen.
? genau ein beliebiges Zeichen.
[abcd] genau ein Zeichen, und zwar eins der in den Klammern ste-
henden. Es dürfen beliebig viele Zeichen angeführt sein.
[a-g] genau ein Zeichen, und zwar a, b, ... oder g. Das Minuszei-
chen bedeutet also "bis".
[~abc] genau ein Zeichen, und zwar ein beliebiges bis auf die Zei-
chen in den eckigen Klammern. Es dürfen beliebig viele Zei-
chen angeführt sein.
Der Punkt zwischen Dateiname und Extender wird dabei wie jedes andere
Zeichen behandelt, "*" paßt also auf alle Dateinamen und nicht nur auf
die ohne Extender.
Beispiele:
* alle Dateinamen.
*.* alle Dateinamen, die einen Extender haben.
*.? alle Dateinamen, deren Extender aus genau einem Zei-
chen besteht.
*.[co] alle Dateinamen mit Extender .c oder .o.
*.[~co] alle Dateinamen außer denen mit Extender .c und .o.
[abcd]*[xyz] alle Dateinamen, deren erstes Zeichen a, b, c oder
d und deren letztes Zeichen x, y oder z ist. Der
Punkt, der den Extender einleitet (falls vorhanden), kann
irgendwo dazwischen stehen.
a[0-9] alle Dateinamen, die aus a, gefolgt von einer Ziffer be-
stehen, also a0, a1, ..., a9.
??[a-z][0-9] alle Dateinamen, die aus zwei beliebigen Zeichen,
gefolgt von einem Buchstaben und einer Ziffer bestehen.
Wenn das Shell-Flag w nicht gesetzt ist, sind die erweiterten Wildcards
außer Kraft gesetzt. Die Shell benutzt dann nur die Wildcards, die von
TOS zur Verfügung gestellt werden.
Das Programm für den Vergleich mit erweiterten Wildcards stammt von Rich
Salz und wurde 1986 geschrieben.
---------------------------------------------------------------------------
FLAGS UND PARAMETER
Jedem Kommando können Flags und Parameter übergeben werden. I.d.R.
werden Parameter benutzt, um festzulegen, womit etwas getan werden soll,
und die Flags legen fest, wie es getan werden soll.
Die Shell teilt die Eingabezeile in Worte auf. Worte werden durch White-
space-Zeichen (Leerzeichen, Tab, Formfeed) getrennt. Durch doppelte (")
oder einfache (') Anführungszeichen können auch Whitespace-Zeichen in
Worten benutzt werden, z.B. ist
a b c d
vier Worte, während
"a b c d"
nur ein Wort ist. Einfache Anführungszeichen verhindern außerdem jede
Art von Interpretation, d.h. innerhalb von einfachen Anführungszeichen
werden
* keine Shellvariablen expandiert
* keine Slashes zu Backslash umgeformt
* keine Escape-Sequenzen (beginnent mit ^) interpretiert
* keine Command-Substitution ausgeführt
$HOME
den Inhalt der Shell-Variablen HOME und
'$HOME'
den String $HOME.
Externen Kommandos werden alle übergebenen Flags und Parameter als
Kommandozeile übergeben. Alle exportierten Shell-Variablen werden den
externen Kommandos im Environment übergeben. Das Betriebssystem limitiert
die Länge der Kommandozeile auf maximal 125 Zeichen. Die Übergabe von
mehr Zeichen ist durch das xArg-Protokoll möglich. Die Flags der internen
Kommandos werden i.d.R. durch ein Minuszeichen eingeleitet. Näheres siehe
commands.doc.
Die Shell benutzt eine Reihe eigener Flags, die mit dem internen Kom-
mando set eingestellt werden können. Siehe hierzu commands.doc.
----------------------------------------------------------------------------
VERKETTETE KOMMANDOS
Kommandos können in einer Zeile durch Semikolon getrennt angeführt
werden. Die Kommandos werden von links nach rechts ausgeführt.
Wenn eine eingegebene Zeile mit einem Dach (^) endet, wird anstelle des
Daches die Fortsetzung der Zeile von der Sekundäreingabe eingelesen. Das
entspricht dem Backslash in Unix. (In TOS ist der Backslash zum Trennen
von Datei- und Ordnernamen reserviert.)
Beispiel:
ec^
ho ha^
l^
lo
entspricht "echo hallo". Dabei kann diese Eingabe sowohl von der
Tastatur als auch aus einem Shellscript oder einer Shellfunktion stammen.
----------------------------------------------------------------------------
SHELLVARIABLEN
Eine besondere Art von internem Kommando ist die Zuweisung eines Wertes
an eine Shellvariable. Alle Shellvariablen sind Stringvariablen. Der
Name einer Shellvariablen kann in beliebiger Reihenfolge Buchstaben,
Ziffern und Underscores (_) enthalten.
Es können bis zu 200 Variablen angelegt werden; wer damit nicht auskommt,
benutze den Software-Support, um eine Version der Shell mit größeren
Kapazitäten zu erhalten. Die Maximalanzahl der Variablen einer Shell
kann mit "ver -l" ermittelt werden.
Jede Shell-Variable hat einen Status, der aus beliebigen (auch null) der
folgenden Eigenschaften besteht:
USR (User)
Die Variable wurde vom Benutzer angelegt oder verändert.
SYS (System)
Es handelt sich um eine Systemvariable, die von der Shell verwaltet
wird. Hierzu gehören z.B. die Positionsparameter $0, $1..., $#, $?
usw.
R/O (Read-Only)
Der Wert der Variablen darf nicht verändert und die Variable darf
nicht gelöscht werden.
EXP (Exportiert)
Die Variable befindet sich im Environment.
Die Eigenschaften USR und SYS können nicht beeinflußt werden. Die
Eigenschaften R/O und EXP können mit den Kommandos `readonly' und
`export' gesetzt und gelöscht werden. Siehe hierzu commands.doc.
DEKLARATION
Shell-Variablen brauchen nicht deklariert zu werden.
ZUWEISUNG
Die Zuweisung eines Wertes an eine Shell-Variable geschieht durch eine
Eingabe der Form
Variable=Wert
z.B.:
NAME=Okami-Shell
Es wird der String "Okami-Shell" der Shellvariablen NAME zugewiesen. In
Unix ist es üblich, Shell-Variablen in Großbuchstaben zu schreiben, es
sind allerdings auch Kleinbuchstaben möglich. NAME und Name sind zwei
unterschiedliche Variablen. Auf die folgende Weise kann einer Variablen
ein leerer Wert zugewiesen werden:
Variable=""
Der Wert der Variablen wird also gelöscht, aber die Variable selber
bleibt bestehen.
Außerdem können die internes Kommandos "read", "fsel", "alert" und
"mouse" zur Zuweisung von Eingaben an Shellvariablen benutzt werden.
Siehe hierzu commands.doc.
BENUTZUNG
Der Wert einer Shell-Variablen kann durch Angabe des Variablennamens mit
vorgestelltem Dollar-Zeichen angegeben werden. In einer Eingabezeile der
Shell werden erst alle Variablen zu den betreffenden Werten expandiert,
bevor die Zeile ausgeführt wird. Shell-Variablen, an die noch kein Wert
zugewiesen wurde, werden als Leerstrings behandelt.
Beispiele:
NAME=Okami-Shell
echo $NAME
erzeugt die Ausgabe "Okami-Shell".
NAME=Okami-Shell
echo Der Name ist $NAME und nicht anders.
erzeugt die Ausgabe "Der Name ist Okami-Shell und nicht anders."
VAR1=$VAR2
weist der Variablen VAR1 den Wert der Variablen VAR2 zu.
VAR1=VAR2
VAR3=VAR1
$VAR1=$VAR3
weist der Variablen VAR2 den String VAR1 zu (sic).
Es ist auch möglich, Shell-Kommandos an Variablen zuzuweisen und dann
ausführen zu lassen:
CC=c:\compiler\cc.ttp
$CC test.c
ruft das Programm c:\compiler\cc.ttp mit dem Parameter test.c auf.
LÖSCHEN
Auf die folgende Weise werden Variablen gelöscht:
Variable=
Dies ist nicht zu verwechseln mit dem Löschen des Inhalts einer Variablen
(siehe oben). Wenn hinter dem Gleichheitszeichen nichts steht, wird die
Variable vollständig gelöscht und belegt danach keinen Platz mehr in der
Variablentabelle.
Dies ist notwendig, da die Shell nur über eine begrenzte Anzahl von
Variablen verfügt. Besonders Shell-Scripts, die Variablen für lokale
Zwecke benutzen, sollten diese Variablen nach der Benutzung wieder
freigeben. Shellvariablen können außerdem mit dem Kommando unset gelöscht
werden.
Beim Löschen verliert die Variable natürlich auch ihren Status. Um den
Status zu erhalten, darf nur der Wert der Variablen gelöscht werden
(NAME="").
Beispiele:
NAME=
Die Shell-Variable NAME wird gelöscht.
unset NAME
Ebenso.
SAVECWD=$CWD
cd c:\work\test
.......................(weitere Kommandos)
cd $SAVECWD
Das aktuelle Verzeichnis (das stets in der Variablen CWD steht) wird
in der Variablen SAVECWD gesichert. Danach wird das aktuelle
Verzeichnis geändert (mit dem internen Kommando "cd"), und es werden
weitere Kommandos ausgeführt. Anschließend wird das aktuelle
Verzeichnis wieder restauriert.
Diese Technik sollte von allen Shellscripts benutzt werden, die das
aktuelle Verzeichnis ändern. Unter Unix werden Shellscripts stets von
Subshells ausgeführt, und das aktuelle Verzeichnis ist eine
Eigenschaft eines Prozesses, weswegen Shellscripts das aktuelle
Verzeichnis ändern können, ohne das aktuelle Verzeichnis der
aufrufenden Shell zu beeinflussen. Die Okami-Shell benutzt keine
Subshells, und daher kann jedes Shell script das aktuelle Verzeichnis
der Shell ändern, was in der praktischen Anwendung nicht immer
erwünscht ist.
Das umständliche Speichern und Restaurieren des aktuellen
Verzeichnisses entfällt, wenn die Shell-Flags x und c gesetzt sind.
Siehe hierzu das interne Kommando `set' in commands.doc.
SYSTEMVARIABLEN
Eine Reihe von Shellvariablen werden von der Shell selber angelegt und
benutzt. Es ist teilweise möglich, die Werte dieser Variablen zu verän-
dern. Diese sind:
OKSH_PROFILE
Das beim Start der Shell zu landende Profile. Muß folglich bereits
beim Start der Shell im Environment vorhanden sein und hat von da an
keine Bedeutung für die Shell mehr.
PS1
Das Eingabeprompt. Kann vom Anwender verändert werden (was
normalerweise im Profile geschieht). Der Defaultwert ist " $ ".
PS2
Das sekundäre Eingabeprompt. Erscheint z.B. bei der Eingabe von
Shellfunktionen. Kann beliebig verändert werden, der Defaultwert ist
"> ".
OKAMISHELL
Die Versionsnummer der Shell. Kann nicht verändert werden.
Diese Variable wird nicht an gestartete Programme weitergegeben und
ist deshalb nur in Shellscripts gesetzt, wenn diese unter der
Okami-Shell laufen. Daher kann das Vorhandensein dieser Variablen
als Test benutzt werden, ob ein Shellscript unter der Okami- oder
einer anderen Shell ausgeführt wird.
TERM
Der Rechnertyp, wird anhand des _MCH-Cookies eingestellt und ist je
nachdem "Atari ST", "Atari Mega ST", "Atari STE" oder "Atari TT".
Wenn kein Cookie-Jar installiert ist, wenn kein _MCH-Cookie
vorhanden ist oder wenn dessen Wert kleiner als 0 oder größer als 3
ist, wird "Atari ST" benutzt. TERM ist in der jetzigen Version der
Shell noch ohne weitere Bedeutung, wird aber von einigen Program-
men benutzt, die eine Unix-ähnliche Termcap verwenden (z.B.
Gnu-Emacs) und sollte dann auf den entsprechenden, von der Termcap
benötigten Wert (z.B. "st" oder "vt52") eingestellt werden.
CWD
Das aktuelle Verzeichnis. Wird nach jedem Wechsel des Verzeichnisses
automatisch aktualisiert und sollte nicht von Hand verändert werden.
(Durch eine Zuweisung an diese Variable wird das aktuelle
Verzeichnis nicht geändert.)
HOME
Das Verzeichnis, aus dem die Shell gestartet wurde (genauer gesagt
das aktuelle Verzeichnis zum Zeitpunkt des Starts der Shell). Kann
nach Bedarf verändert werden.
ETC
Das Verzeichnis, in dem die Shell Hilfsdateien wie z.B. die Textdatei
für das help-Kommando erwartet. Wird bei Programmstart auf denselben
Wert wie HOME eingestellt und kann beliebig verändert werden.
SHELL
Hier soll der vollständige Aufrufpfad des Shellprogramms eingetragen
sein. Da die Shell diesen nicht mit völliger Sicherheit selber
bestimmen kann, wird hier $HOME\sh.ttp eingetragen. Kann beliebig
angepaßt werden, wenn diese Angabe einmal nicht zutrifft. Wird nicht
von der Shell, aber von einigen Programmen benutzt (z.B. Micro-Emacs
oder Pure C). Wer ein neues Programm schreibt, sollte die Shell
lieber über den _shell_p-Zeiger aufrufen.
PAGELEN
Die Anzahl der Zeilen auf dem Bildschirm. Wird von dem internen
Kommando pg (bzw. more) benutzt. Kann beliebig eingestellt werden.
Die Defaulteinstellung ist 23.
PIPDIR
Das Laufwerk und der Pfad, auf dem die Hilfsdateien von Pipelining,
Command Substitution usw. erzeugt werden. Muß auf einem
beschreibbaren Laufwerk (am besten auf einer Ramdisk) liegen. Die
Defaulteinstellung ist $HOME. Kann beliebig verändert werden.
NULL
Der Name des Gerätes oder der Datei, an die die Ausgaben geleitet
werden, die zum Null-Gerät (NULL:) umgeleitet werden. Kann verändert
werden. Die Defaulteinstellung ist "PRN:" (paralelle Schnittstelle)
oder "u:\dev\null", wenn MiNT installiert ist.
Wer MiNT nicht benutzt und einen Drucker hat, sollte hier eine Datei
z.B. auf der Ramdisk eintragen. Die Einstellung AUX: für die serielle
Schnittstelle ist nicht möglich, da diese Schnittstelle von der
Standard-Fehlerausgabe belegt ist.
(Und was lernen wir daraus? So schnell wie möglich MiNT
installieren.)
PATHSEP
Die Zeichen, die als Trennzeichen in den Variablen PATH, XEXT usw.
gelten sollen. Die Voreinstellung ist ",;", was bedeutet, daß in PATH
usw. einzelne Felder mit Kommata oder Semikolons getrennt werden
können. Wenn in MiNT nur das unifizierte Dateisystem auf Laufwerk U:
benutzt, kann in PATHSEP auch den Doppelpunkt eintragen und die
Felder in PATH wie in Unix mit Doppelpunkten trennen.
XEXT
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Extendern. Dateien mit einem der hier aufgeführten Extender können
als Binärprogramme gestartet werden. Die Defaulteinstellung ist
".prg,.tos,.ttp,.app". Die Punkte vor den Extendern müssen mit
angegeben werden. Kann beliebig verändert werden.
SEXT
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Extendern. Dateien mit einem der hier aufgeführten Extender können
als Shellscripts gestartet werden. Die Defaulteinstellung ist ".sh".
Die Punkte vor den Extendern müssen mit angegeben werden. Kann
beliebig verändert werden.
GEXT
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Extendern. Binärdateien mit einem der hier aufgeführten Extender
werden als GEM-Programme, d.h. nicht direkt, sondern über die
Shellfunktion gemexec gestartet. Siehe hierzu den Abschnitt über
gemexec in commands.doc. Die Defaulteinstellung ist ".prg". Kann
beliebig verändert werden.
Wie in commands.doc erklärt, müssen die Extender nicht unbedingt
denen von ausführbaren Programmdateien entsprechen.
MANEXT
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Extendern. Dateien mit einem der hier angeführten Extender werden von
der Online-Hilfe mit der Helptaste oder dem Kommando man als
Anleitungsdateien erkannt. Die Voreinstellung lautet ".doc,.man".
Kann beliebig verändert werden.
PATH
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Pfaden. Bei der Eingabe eines externen Kommandos ohne vollständige
Pfadangabe wird die Datei auf den hier angegebenen Pfaden gesucht.
Die Defaulteinstellung ist ".,..,$HOME,$HOME\bin". Kann beliebg
verändert werden.
CDPATH
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Pfaden. Beim Wechsel des aktuellen Arbeitsverzeichnisses mit "cd"
wird, wenn der bei cd angegebene Pfad nicht existiert und nicht
absolut angegeben ist, auf den in CDPATH gespeicherten Pfaden
gesucht. Die Defaulteinstellung ist "..,\". Kann beliebig verändert
werden.
MANPATH
Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten
Pfaden. Auf diesen Pfaden sucht die Online-Hilfe (Helptaste oder das
Kommando `man') nach Anleitungsdateien. Die Defaulteinstellung ist
"$HOME\doc". Kann beliebig verändert werden.
HELPFILE
Der Name der Datei, aus der die Erklärungen, die bei Druck auf die
Help-Taste ausgegeben werden, stehen. Die Default einstellung ist
"$HOME\doc\commands.doc". Kann beliebig verändert werden.
CLIPDIR
Enthält den Pfad des GEM-Clipboards. Wird durch die Kommandos gon und
clipb initalisiert, die Voreinstellung bei Programmstart lautet
"X:\scrapdir\scrap.*", wobei X: das Bootlaufwerk ist. Diese Variable
sollte nur mit dem Kommando clipb verändert werden. Siehe hierzu auch
commands.doc.
Enthält bei Eingabe eines Kommandos den Namen des Kommandos und beim
automatischen Aufruf der Funktion gemexec den vollständigen Pfad des
aufzurufenden Programms.
1
Enthält den ersten Parameter der Eingabezeile.
2
Enthält den zweiten Parameter der Eingabezeile usw.
#
Enthält die Anzahl der Parameter der Eingabezeile.
*
Enthält die vollständige Eingabezeile.
?
Enthält den Rückgabewert des zuletzt ausgeführten Kommandos.
Die folgenden Shellvariablen werden nur von einzelnen internen Kommandos
benutzt.
COLUMNS
von `scr': Anzahl der Zeilen auf dem Bildschirm.
DIALPREFIX
für `dial': Präfix des Modem-Wählkommandos.
Nach dem Start der Shell werden Variablendefinitionen aus dem Environment
gelesen und ausgeführt. Auf diese Weise können alle Variablen (auch
LOGNAME usw.) geändert, aber keine gelöscht werden.
----------------------------------------------------------------------------
EIN/AUSGABE-UMLEITUNG
1) Für interne Kommandos
Die Eingabe, Ausgabe und Fehlerausgabe jedes internen Kommandos kann auf
einfache Weise in bzw. aus einer beliebigen Datei oder zu bzw. von einem
Gerät umgeleitet werden.
Folgende Umleitungsmöglichkeiten stehen zur Verfügung:
<Datei
Umleitung der Eingabe
>Datei
Umleitung der Ausgabe, die Datei wird vorher gelöscht
>>Datei
Umleitung der Ausgabe, sie wird an die Datei angehängt
2>Datei
Umleitung der Fehlerausgabe, die Datei wird vorher gelöscht
2>>Datei
Anhängen der Fehlerausgabe an die Datei
Anstelle von "Datei" können auch die folgenden Geräte angegeben sein:
CON: Konsole (Default)
PRN: parallele Schnittstelle (Drucker)
AUX: serielle RS232-Schnittstelle (Modem)
NULL: ignorieren
Das Gerät NULL:, auch Null-Gerät genannt (in Unix: /dev/null), wird
nicht vom Betriebssystem des ST unterstützt, sondern von der Shell
simuliert. Der Zweck eines Null-Gerätes ist, die Ausgabe oder
Fehlerausgabe eines Kommandos zu unterdrücken. Die Shell-Variable NULL
gibt an, wo die Ausgabe, die an NULL: umgeleitet wird, tatsächlich landen
soll. Normalerweise ist das die Druckerschnittstelle; wenn diese von
einem Drucker belegt ist, sollte man eine reguläre Datei z.B. auf der
Ramdisk angeben (NULL=G:/null).
Wer MiNT benutzt, hat damit keine Probleme, da MiNT ein Null-Gerät zur
Verfügung stellt. Unter MiNT sollte man NULL auso auf u:/dev/null
einstellen (was die Shell beim Starten automatisch tut).
Beispiel:
rm *.dup
löscht sämtliche dup-Dateien, gibt aber eine Fehlermeldung aus, wenn
keine solchen Dateien vorhanden sind oder wenn sie schreibgeschützt
sind. Um die Fehlermeldung zu unterdrücken, kann man stattdessen
schreiben:
rm *.dup 2>NULL:
Dadurch werden die Fehlermeldungen an das Null-Gerät geleitet.
(Nebenbei: bei Verwendung von
rm -f *.dup
werden auch keine Fehlermeldungen ausgegeben, allerdings werden damit
auch schreibgeschützte Dateien gelöscht.)
Wenn keine Umleitung angegeben ist, geht die Eingabe von der Tastatur
und die Ausgabe und Fehlerausgabe zum Bildschirm, genauer gesagt zu der
Standard-Ein- und -Ausgabe der Shell selber (die beim Start von sh.ttp
angegeben werden kann).
PIPELINING
Die Idee des Pipelining ist es, die Ausgabe eines Kommandos zur Eingabe
des nächsten zu machen. So schreibt z.B. das memex-Kommando einen
Speicherbereich auf seine Ausgabe, und das hd-Kommando fertigt von
seiner Eingabe ein Hexdump an. Mit dem Pipelining können beide Kommandos
verbunden werden, d.h. man bekommt ein Hexdump eines Speicherauszuges.
Um zwei Kommandos in einer Pipeline zu verbinden, wird zwischen sie ein
senkrechter Strich (|), auch Pipe genannt, gesetzt, z.B.:
hd sh.ttp | pg
Die Ausgabe des hd-Kommandos (ein langer Hexdump) wird zur Eingabe des
pg-Kommandos, wodurch der Hexdump seitenweise angezeigt wird. Die
Schreibweise a | b ist äquivalent zu: (a und b sind beliebige Kommandos
incl. ihren Parametern)
TMP=$PIPDIR\pip$$
a > $TMP
chmod +h $TMP
b < $TMP
rm $TMP
unset TMP
(mit drei kleinen Unterschieden: 1. zum Bilden eines eindeutigen
Dateinamens wird nicht $$, sondern ein anderer Zähler benutzt, 2. die
Datei wird nach dem Anlegen und nicht erst nach dem Ende von a unsichtbar
gemacht und 3. es wird keine Shellvariable benutzt.)
Dies ist ein wesentlicher Unterschied zu Unix, wo alle an einer Pipe
beteiligten Kommandos (Prozesse) gleichzeitig laufen. Eine Pipeline ist
unter Unix eine Einrichtung des Betriebssystems, die von der Okami-Shell
nur simuliert wird. (Wie gesagt, Okami ist eine Shell und kein
Betriebssystem.)
Das Laufwerk und der Ordner, auf dem die Pipe-Dateien erzeugt werden,
kann mit der Shellvariablen PIPDIR eingestellt werden. Die
Defaulteinstellung beim Start der Shell ist $HOME. Dadurch bietet sich
die Möglichkeit, die Pipe-Dateien auf ein schnelles Laufwerk zu legen,
z.B. auf eine Ramdisk oder eine wenig benutzte Partition der Festplatte.
VORSICHT: Wenn $PIPDIR auf einen nicht existierenden Ordner oder
Laufwerk eingestellt ist, erscheinen anstelle von Pipe-Operationen nur
Fehlermeldungen der Form:
Error: cannot open .....\pip3
(Anstelle von ...... steht der Inhalt von PIPDIR.)
In diesem Fall wird keins der an einer Pipe beteiligten Kommandos
ausgeführt.
Abhilfe schafft das Kommando
mkdir -r $PIPDIR/
im Profile nach dem Einstellen von PIPDIR. Dadurch werden alle zu
$PIPDIR gehörenden Unterverzeichnisse erzeugt.
Die Pipe-Datei kann mit folgendem Kommando sichtbar gemacht werden:
ls -a $PIPDIR\pip* | cat
INLINE-DOKUMENTE
Als Inline- oder Hier-Dokument wird eine spezielle Art der
Eingabeumleitung bezeichnet, bei der die einem Kommando zuzuführende
Eingabe direkt von der Eingabe oder z.B. dem Shellscript stammt.
Beispiel:
cat <<eof
Das ist ein Text, der
zu der Eingabe des cat-
Kommandos wird.
eof
Diese Zeilen können von der Tastatur eingegeben, aber auch in einem
Shellscript oder einer Shellfunktion stehen.
Die Shell betrachtet die Zeichenkette nach "<<" als Terminierungsstring
und schreibt die nachfolgenden Zeilen in eine Datei, die dann als Eingabe
des Kommandos benutzt wird. Das Inline-Dokument wird durch eine Zeile
beendet, die nur (bis auf führende Leerzeichen) aus dem
Terminierungsstring besteht.
Wenn den << direkt ein Minuszeichen folgt, also z.B.
cat <<-eof
, werden alle führenden Leerzeichen der Eingabezeilen entfernt. Das
Minuszeichen gehört nicht zu dem Terminierungsstring.
Die Shell führt auf allen eingelesenen Zeilen Variablensubstitutionen und
Command Substitution aus.
Inline-Dokumente sind sinnvoll in Shellscripts, die mehrzeilige Ausgaben
erzeugen sollen, wodurch sich Reihen von echo-Kommandos vermeiden
lassen.
2) Für externe Kommandos
Theoretisch funktionieren sämtliche Ein/Ausgabe-Umleitungen inklusive der
Pipeline auch mit externen Kommandos. In der Praxis jedoch erlauben
nicht alle Programme diese Möglichkeit, z.B weil sie Tastatur und
Bildschirm direkt über die entsprechenden Bios-Funktionen (Bconout etc.)
ansprechen, die sich nicht umleiten lassen. (Mit MiNT lassen sich auch
solche Programme umleiten.)
Die Okami-Shell leitet die Ein/Ausgabe auf Gemdos-Basis um, was bedeutet,
daß alle Programme, die für die Ein/Ausgabe Gemdos-Funktionen (Cconout
etc.) benutzen, umgeleitet werden können. C-Programme, die die
Standard-Streams stdin und stdout benutzen, werden normalerweise korrekt
umgeleitet.
GEM-Programme sind von vornherein gegen jede Art der Umleitung immun, da
sie den Bildschirm über den entsprechenden VDI-Gerätetreiber ansprechen.
----------------------------------------------------------------------------
COMMAND SUBSTITUTION
Die Okami-Shell bietet die Möglichkeit, die Ausgabe eines Kommandos in
eine Kommandozeile einzubauen. Möchte man z.B. eine Ausgabe wie "Es sind
... Bytes frei" erzeugen, in die die Anzahl der freien Bytes (die mit
dem Kommando mem ermittelt werden kann) eingebaut sind, dann kann die
Ausgabe von mem auf folgende Weise in das echo-Kommando eingebaut werden:
echo Es sind `mem` Bytes frei.
Alles, was in einer Eingabezeile zwischen zwei Accent grave (`) steht,
wird als Kommando betrachtet und ausgeführt. Die Ausgabe wird anstelle
der in Accent grave stehenden Zeichenkette in die Eingabezeile
eingesetzt. Dieses Verfahren wird als Command Substitution bezeichnet.
Wenn die Ausgabe des Kommandos über mehrere Zeilen geht, wird nur die
erste Zeile (also die Ausgabe bis zum ersten Zeilenende) benutzt. Als
Zwischenspeicher für die Ausgabe des Kommandos wird eine Datei namens
$PIPDIR/csubXXXX benutzt. XXXX ist hierbei eine laufende Nummer, und
$PIPDIR ist das Laufwerk, über das auch die Pipelining- Operationen
laufen. Diese Datei wird nach Verwendung gelöscht.
Beispiele:
Speichern der Shellflags:
SET=`set -`
Wiederherstellen mit:
set $SET
Anzeigen einer Datei, die in demselben Ordner liegt wie $FILE1, die aber
denselben Basisnamen wie $FILE2 hat:
cat `dirname $FILE1`/`basename $FILE2`
Löschen der ältesten Datei mit Nachfrage:
rm -i `ls -t`
----------------------------------------------------------------------------
ENVIRONMENT
Die Okami-Shell bietet die Möglichkeit, Definitionen von Shell-Variablen
in das Environment zu übernehmen. Diese Definitionen werden dann allen
gestarteten Programmen übergeben. Mit dem internen Kommando export
können beliebige Shellvariablen in das Environment ausgenommen oder
daraus entfernt werden.
In der Basepage eines Programms steht ab Offset 0x2c die Adresse des
Environment-Strings. Diese Adresse wird berechnet als:
char *BaseAdr;
char *EnvAdr;
EnvAdr = *(char **)(BaseAdr+0x2c);
BaseAdr ist die Adresse der Basepage (wird irgendwie vom Compiler zur
Verfügung gestellt). EnvAdr ist dann die Adresse des Environment-Strings.
Dieser String hat folgende Syntax:
EnvString ::= { VarDefinition } "\0"
VarDefinition ::= VarName "=" VarWert "\0"
Beispiel:
"a=Variable a\0b=Variable b\0usw=undsoweiter\0\0"
Es werden folgende Variablen gesetzt:
a auf "Variable a"
b auf "Variable b"
usw auf "undsoweiter"
----------------------------------------------------------------------------
MINT-UNTERSTÜTZUNG
Die Okami-Shell benutzt und unterstützt MiNT, das
Multitasking-Betriebssystem für TOS-Rechner. Wenn MiNT installiert ist,
dann:
* meldet die Shell sich als MiNT-Domain-Prozess an.
* wird die Shellvariable NULL als u:/dev/null voreingestellt.
* wird die MiNT-Signalverarbeitung verwendet. Es können dann interne
Kommandos mit Ctrl-C abgebrochen werden. Mit Ctrl-\ wird die Shell
abgebrochen.
* können mit `&' Hintergrundprozesse gestartet werden.
* wird die Tastatureingabe des Zeileneditors mit Fselect abgewicklt,
d.h. die Shell benötigt während der Eingabe praktisch keine CPU-Zeit.
* liefert das Kommando `ps' eine formatierte Ausgabe der Dateien in
u:/proc.
* liefert das Kommando `time' zusätzlich User- und Kernalzeiten.
* benutzt das Kommando `sleep' keine Warteschleife, sondern
Systemaufrufe, um während des Wartens keine CPU-Zeit zu benötigen.
* beendet das Kommando `shutdown' alle Prozesse, bevor es das System
abschaltbereit erklärt.
* kann mit dem Kommando `ver -m' die Versionsnummer des installierten
MiNT ermittelt werden.
* sind die folgenden Kommandos und Optionen nutzbar:
id User- und Gruppennummer ermitteln
kill Signale an Prozesse senden
ln Links erzeugen
ls -s symbolische Links anzeigen
tty Terminalnamen ermitteln
----------------------------------------------------------------------------
GRÜSSE
1) An die Firma GRP in Aachen, für lebenswichtige Kenntnisse in C und
Unix.
2) Für die Begleitung in zahllosen Stunden voller Lust und Frust vor der
flimmerfreien Flimmerkiste: Mike Oldfield, The Beatles, Little Richard,
Bill Haley, Tommy Roe, Lesley Gore, Pat Boone, Elvis Presley, Chuck
Berry, Del Shannon, Chris Montez, Billy Joe Royal, The Box Tops, The
Cascades, Trini Lopez, Chris Andrews, Mary Hopkins, The Tremoloes, Bobby
Vee, The Kinks, The Turtles, The Swinging Blue Jeans, Shane Fenton & The
Fentones, The Piltdown Men, Helen Shapiro, Cliff Richard, The Cowsills,
Jerry Lee Lewis, Melanie, Buddy Hollie, The Lovin' Spoonful, The
Crystals, The Knickerbockers, The Crests, Every Mother's Son, The Shangri
Las, Bernard Cribbins, The Shadows, Frank Ilfield u.v.a.
Atari ST, GEM, Unix, MS-Dumpf usw. sind eingetragene Warenzeichen von -
ach das wißt Ihr schon? Na gut.
Diese Anleitung wurde ursprünglich als reine Ascii-Datei geschrieben,
dann in eine Tempus-Word-Datei umgeformt und wegen der absoluten
Unfähigkeit von Tempus Word, Texte vernünftig formatiert als Ascii-Datei
auszugeben, in nroff umgeschrieben und mit "miniroff" formatiert.